Supreme Commander

Publisher: THQ

We used the full retail version of Supreme Commander with the version 3220 patch applied. Supreme Commander is developed by Chris Taylor, the creator of the Total Annihilation series, and his development team, Gas Powered Games. Together, Taylor and his team have created what is widely regarded as the spiritual successor to one of the greatest RTS games of all time.

SupCom is a hugely tactical and strategic monster on a massive scale -- hundreds of units can appear on screen at once. It's a massive departure from anything else we've recently seen in the genre. It's one of (if not) the first RTS to allow the player to scroll out to view the scale of battle in its entirety.

More importantly from a graphics point of view, Supreme Commander is due for a graphical makeover when Gas Powered Games introduces DirectX 10 support later this year (this has since been cancelled - Ed.). The developers say the patch will bring a host of image quality enhancements, on top of some performance improvements -- these should definitely help in some of the more intense situations where there are literally hundreds of units on screen at any given point in time.

We used the game's in-built performance test during our testing, as this provides over seven minutes of variable gameplay -- both zoomed in and out -- that should represent typical scenarios that a user is likely to encounter whilst playing the game. Due to the massive scale of the game, it's incredibly hard to accurately quantify performance in any other way.






First of all, you'll notice that there are no Radeon HD 2900 XT CrossFire numbers for Supreme Commander. The reason for this is that the game would run for around two minutes before crashing out. A single HD 2900 XT ran through our tests continuously without any issues, so it's obviously a case of driver immaturity - we hope this will be fixed soon, as the game could kill for a pair of HD 2900 XTs at anything above 1920x1200.

Secondly, we're heavily CPU limited at lower resolutions in this title, as I'm sure you'll notice from the frame rates with the SLI configurations tested. A quad-core CPU may help matters a little here, but the sheer number of units on screen at any time is a huge CPU clock cycle drain in DirectX 9 (going back to the small batch problem). It'll be interesting to see if that problem is removed when the DirectX 10 patch arrives at some point - if there's any game that's going to show it, this is probably it.

Single card performance still shows some nice scaling over the range of hardware tested though and the situation isn't good for the Radeon HD 2900 XT. It loses out to both the similarly priced BFGTech GeForce 8800 GTS 640MB OC, and also the 320MB version that sells for quite a bit less! The gap is around 26 percent at 1600x1200 4xAA 16xAF, or 40 frames per second and 32 frames per second to put things into perspective a little.

At 1920x1200, the trend continues, but the Radeon HD 2900 XT gains a bit of ground on BFGTech's GeForce 8800 GTS 640MB - the performance deficit is down to 22 percent with 4xAA enabled. The multi-GPU CPU limitations disappear at 2560x1600 and we start to see some nice scaling - even with only 2xAA applied. At these settings, the Radeon HD 2900 XT gains more ground on the GeForce 8800 GTS 640MB - the deficit is reduced to just ten percent (or two frames per second) and the card's performance surpasses the GTS 320MB.

With 4xAA enabled at 2560x1600, the gap increases back up to 16 percent - I guess there's still quite a bit of Ring Bus optimisation to do in the drivers here, as the difference in available bandwidth is massive. It could potentially be a problem with the MSAA resolve unit too, with unnecessary load being placed onto the shader units.